[レポート]Governance and security with infrastructure as code #reinvent

はじめに

CX事業本部の佐藤智樹です。

今回はre:Invent開催中に実施されたセッション「Governance and security with infrastructure as code」についてレポートします。

セッション概要　

In this session, learn how to use AWS CloudFormation and the AWS CDK to deploy cloud applications in regulated environments while enforcing security controls. Find out how to catch issues early with cdk-nag, validate your pipelines with cfn-guard, and protect your accounts from unintended changes with CloudFormation hooks.

このセッションでは、AWS CloudFormationとAWS CDKを使用して、セキュリティ管理を実施しながら規制環境にクラウドアプリケーションを展開する方法について学びます。cdk-nagで問題を早期に発見し、cfn-guardでパイプラインを検証し、CloudFormation hooksで意図しない変更からアカウントを保護する方法について学びます。

登壇者

• David Hessler氏 Senior DevSecOps Consultant, AWS
• Eric Beard氏 Senior Solutions Architect, AWS

公開動画

セッションの内容

今日はワークロードの展開や厳しく規制された環境を支援するために、金融セクターや公共セクターなど、厳格なセキュリティ管理を実施しなければならない場所に向けての話をします。とはいえ、この話は誰にでも関係することだと思います。会社の規模、歴史、業種を問いません。誰もが、ガバナンスとセキュリティについて考える必要があります。

まず安全性の概念から説明します。私たちは非常に高いレベルでこれを行い、さまざまなセキュリティ標準をサポートしています。そして、コンプライアンス要件に対応しています。PCI DSSを始め、私たちは自分達のプロセスに安心と自信を持っていますが、それは、継続的にやってくる数多くのサードパーティのクライアントがいるからです。

あなたやあなたの会社がクラウドを導入したい理由は何でしょうか。それは、価値あることを迅速に提供し素早く差別化を図りたいからです。そこで今日は、このようなツールを使って、どのように構築するかを考えていきます。

インフラストラクチャをコード化します。インフラストラクチャのコードから得られる最も大きなメリットは、一貫したインフラの操作にあります。

全く同じリソースを複数の環境にデプロイしたい場合に、それを正確に実現することができます。

IaCのソースコードのバリデーションは上記のようなツールでも実現できます。プロビジョニングする際は上記のようなOSSのフレームワークが使えます。

AWS CDKの場合は、高レベルの言語を使えば、あらゆる利点が得られるし、使いやすいし、抽象化もできます。この画面では、十数行のコードでネットワーク全体を構築しています。

今度はDevOpsについてお話しします。私は今日、お客様がクラウドで困難な問題を解決する手助けをすることに情熱を注いでいます。特にコンプライアンス意識が高い業界などです。AWSがDevOpsとセキュリティに適用してこれを解決することについて少しお話しましょう。AWSでは、私たちのDevOpsに対する考え方は、カルチャーから始まります。カルチャーには3つあります。Break things down, Threat Teams as autonomous business, Automate everything.

私たちは6~10人のマイクロサービスのチームを多く持っており、それらが集まってプロダクションサービスになっています。彼らは、大企業内で小さなスタートアップのように振る舞い、複数のチームと調整することなくサービスを展開できるようになっています。チームは機能開発にのみ専念するのでなく、運用、グロース、セキュリティコンプライアンスも担当します。また全ての作業は自動化していきます。

IaCはAWSでAWSを構築するための重要なコンポーネントです。AWS CDKはAWSのデフォルトの方法になります。

それではAWS全体の視点であるDevOpsのSagaについてお話しします。クラウド内アプリの設計、提供、デプロイ、監視、運用経験に基づいて、何千もの企業のクラウドでの変革を支援しています。DevOps Sagaはその経験を説明するコア機能です。組織の採用、開発ライフサイクル、品質保証、自動化されたガバナンス、可観測性、それぞれ経験の柱を構成するSagaです。

ここにはセキュリティ、ガバナンス、信頼性、レジリエンスなどはないことに注意してください。AWSではセキュリティが最重要事項で、セキュリティは各Sagaが通過するためのスレッドにならなければならないということです。

DevOpsではカルチャーが大事であり、セキュリティファーストな組織を意地できる適切な認知負荷の管理が必要です。これらのSagaはそれぞれ実際に、ベストプラクティスを特定し、結果を重視する一連の機能であり、訂正的な尺度です。DOP207の別セッションでは、DevOps SagaとAWS WellArchitected Toolカスタムレンズを使用して、Sagaの成功を測定する方法を掘り下げます.

DevOpsができたので次はセキュリティコントロールです。Directive,Preventative(予防)、Detective(発見)、Responsive(応答)の4種類のセキュリティコントロール、発見的なものが私たちが目指しているものであり、セキュリティ分野からのものです。これは開発者にリアルタイムでフィードバックを提供し、、修正可能であることを示します。予防は物事の発生自体を止めます。重要なツールの一つがpre-commit hookです。コミット前に検知しコードの共有を止めます。もう一つはSCPによるAPIコール自体の停止です。

Responsiveは最後の防衛線だと考えます。タグ適用や暗号化の強制などぶつかった場合にすぐに修正する。これらの問題は開発者に対するフィードバックが分かりにくいことです。なぜそれが重要なのかというと例えばS3バケットの暗号化が必須の場合、S3を最初使っていないと暗号化を必須とする設定を入れ忘れる場合もあります。しかしながら、Progressive deploymentsは非常に役に立ちます。Canary ReleaseやBlue/Green Deploymentによって、バグによる顧客影響を最小化することができます。

AWSは最近デプロイメントリファレンスアーキテクチャ(DPRA)を公開しました。DPRAは、セキュリティをよりスライドの左側（開発者の手元に近い環境）にシフトさせていきます。これにより高速なフィードバックループを実現します。ガバナンスに関するシステムとの対話は自動化されます。AWSでは1年に100万回のデプロイと98のセキュリティフレームワークステーション、認証を維持しています。

ローカル開発ではDirective Controlで制御します。ソースフェーズではに移ります。クラウドではすべてがコードになる可能性があります。インフラ、アプリだけでなく、DB構造、スキーマ、静的アセットもコードで記述できます。ビルドフェーズではガードレールによる制御が発生します。ソフトウェアコンポーネント分析、セキュアな部品などをパイプラインによって絞り込みます。

AWSでは3段階のデプロイを推奨しています。Beta環境、これはアプリが正常に動くかを確認します。青のボタンは正しい色合いですか？など機能的なものからセキュリティチェックもここにテストとして組み込みます。結合/受入テストが重要になります。Gamma環境では、コンプライアンスやレジリエンス、OWASP TOP 10などをチェックします。またロギングや運用観点、コンプライアンス、セキュリティの観点から適切なデータが得られることを確認します。Synthetics Monitoringで本番の監視を続け、主要なKPIを満たすかやワークロードの継続を確認します。失敗する場合は段階的なロールバックを実行します。

特定の事故が発生しフローの後半で発見された場合、Directiveで検知したらPreventionに移行したくなります。この後はその移行方法のためのツールをエリックから紹介します。

佐藤補足：リファレンスアーキテクチャのことをDPRAと言っており、最後に紹介があったのでこちらにリンクを貼っておきます。

ここからは先ほどのスライドの各セクションにDive Deepして説明していきます。開発者がコードに取り組むフェーズを加速しテストサイクルをできるだけ早く反復できるようにしたいと考えています。すべての開発者がSandboxアカウントを持つ。これはControlTowerやOrganizationsによるアカウントベンディングマシーンで自由な作成を実現できます。これらのアカウントにはガードレールによって規制を入れることができます。偶発的な高額請求も防止できます。

これらは多くの企業でできていないことです。コストの問題でできないということを聞きます。月アカウントに50~200ドルかかるとします。しかしながら、開発者の時間による給与のコストや変更時のblast radius(爆発半径、何らかの操作で影響を与える範囲のこと)をみると、他の人が何時間か停止するだけでエンジニアの給料から考えるとマイナスになります。開発者が独自のアカウントを持つと他の人に気にせずデプロイできるようになります。

この後はコードレビューで一旦手が遅くなります。このコードが問題ないことを確認するためAmazonではトランクベースの開発をしています。Gitflowは使用せず、ブランチベースの開発も使用しません。コードレビューには短い期間のブランチを使用します。PRがマージされると、mainブランチにマージされます。すべてのテストに合格すると、変更がデプロイされます。デプロイはすべて自動化されており、人手の作業を含んだゲートはありません。QAテスターもおらず、Beta, Gamma環境のテスターもいません。

すべての作業は自動化されます。リンターを実行し依存関係を取り込みコンパイルします。これらのコントロールの多くを開発者側に置いておくことで、ビルドサーバーより前に問題をキャッチできます。

Beta, Gamma, Productionにデプロイする際、3つのアカウントとは別にCI/CDアカウントをプロビジョニングして使用します。状況に応じてもっと多くのアカウントを使う場合もあります。これはあくまで出発点です。

Betaアカウントは開発チームが管理者となります。ロールやCLIを制限せず自由に使える必要があります。ここでトラブルシューティングを行います。Gammaアカウントは、本番環境と同じように扱います。このアカウントは製品と同じようにロックし、ロードテストなどの模擬テストを実行します。このテストに合格したらProductionにデプロイされます。

AWSの場合は、まず1,2のリージョンと徐々に反映していきます。もし問題があればロールバックします。問題がなければ最終的に全部のリージョンにデプロイされます。コードレビューからすべてロールアウトされるまで数時間、数日またはそれ以上の時間がかかる可能性があります。

ここからは開発者向けのツールを紹介します。cdk-nagは、 cdkに直接プラグインできるツールです。cdk-nagはコードに直接埋め込みます。cfn-nagに影響を受けており、特定のコンプライアンスを満たすパックがあります。cdk-nagは適合しない場合、cdkの合成を中断します。開発者はcdk-nagのエラーを確認して変更を加えることができます。これにより開発者は適切なフィードバックを即座に得ることができます。

次はcfn-nagです。cdkを使わずに命令型コーディングに固執する場合CloudFormationを使用したとします。その場合CloudFormationに対応するcfn-nagが使えます。cdk-nagと同じように警告を表示しフィードバックを得ることができます。

次がcfn-guardです。これはすべてのチャックを完全に実施したい場合に使用します。cfn-guardはコンプライアンスパックではなく、ルールを記述できるDSLを使います。cfnという名前ですが、Terraformにもk8sにも使用できます。

最後は、Amazon CodeWhispererです。IDEのプラグインとして提供され、関数名を入力すると実装を機械学習で想定しコードを挿入できます。

それでは、ここからはビルドフェーズに入ります。コードをmainブランチにマージしましたこの時点ではまだレビューは終わっていません。LGTMはおそらく最良のコードレビューではないという想定から、プラグインによるコードレビューを実施します。CodeGuruは現在はPythonとJavaで使用できます。CodeGuruは安全性の低い関数の使用の検出などが可能です。

CodeBuildは、AWS上でビルドを実行するためのサービスです。CodeBuildを使えばJenkinsなどと比べて、ビルド時だけコンテナを起動するので料金を安く済ませることができます。テストやBanditでセキュリティ脆弱性の発見も実行できます。

ビルドプロセス中にできる次のことは、イメージスキャンです。ベーシックスキャンでは、Claire OSS ProjectのCVE DBを使い、Inspectorはプッシュ時にスキャンし脆弱性を確認できます。

またこれらの素晴らしいAWSパートナー製品を使うができます。Checkmarxは、静的セキュリティスキャン製品の有名なものの1つです。JFrogは、コードアーティファクトに関わるものです。彼らが特に強みとしているのはサプライチェーン分析です。その他Contrast, Snyk, Veracodeなどの製品はCodePipelineやCodeBuild、CodeDeployなどと直接統合できます。詳細は、AWS Security Competency Partnersのリストを確認することをお勧めします。

これまでセキュリティの開発者へのシフトレフトについて話してきました。 指示的なフィードバックでセキュリティ水準を上げていきます。ただ監査人としては機能している証明が必要だという話になるときもあります。CloudFormation hooksは予防的な統制が可能です。Cfnの実行中に評価され、リソースの作成を事前に止めることができます。

デプロイ後に重要なツールもあります。 1つ目はCloudFormation drift detectionです。Cfn外部での変更が発生した時に開発者は変更を検知することができます。DynamoDBへの設定変更などいくつかのリソースで使用できます。

2つ目はIAM Access Analyzerです。リソースにアクセスできるロールができた場合に、SecurityHub→EventBridge→SNSを経由して通知を受け取ることができます。

すべてのセキュリティツールについて詳しく説明するつもりはありませんが、AWSには230を超えるツールがあります。デプロイ後のセキュリティ検知を行うための8つのサービスをここでは挙げておきます。

それでは今日学んだことをまとめましょう。最初にDevOps PipelineでDevopsとセキュリティ制御がどのように連携するして迅速なフィードバックループやセキュリティのシフトレフトを実現するのかを紹介しました。ツールとしては、CodeGuru、cfn-nag、cdk-nag、CodeWhisper、cfn-guardなどを紹介しました。

最後にCloudFormation Guardをhooksに変換するコードと紹介したデプロイパイプラインのリファレンスアーキテクチャについてリンクをおきます。

所感

セキュリティをどうやって開発者側の作業サイクルに寄せていくのかというシフトレフトに関する話が中心にされていて、普段の開発で生かせるような部分もありました。またAWSが実際にサービスをデプロイする際のリファレンスアーキテクチャについても公開されており非常に勉強になりました。単なるCanary DeployやBlue/Greenデプロイだけでなく、デプロイを自動化するためどこまでレビューやロードテストなどが自動適用されているかが楽しく聞けたため記事にしました。パイプラインのリファレンスアーキテクチャについては、今後別記事でも紹介します。

全社やチームでのコンプライアンスやシフトレフトをどのように実現するか悩んでいる方や、既にある程度実現している方にとっても再度新情報をチェックできる発表だったかと思います。この記事がどなたかの役に立てば幸いです。